As service provider networks and service offerings continue to evolve, the corresponding operations model used by service providers to manage those networks and service offerings, and the associated network assets, tend to evolve as well. As a result, large service providers often change operations models for managing the networks and services by adding new network operations centers, deleting existing network operations centers, realigning network operation center responsibilities, and changing network operation center geographic scopes of responsibility.
Unfortunately, in the case of virtual private networks, reconfiguration of a service provider operations model (and the resulting changes to the associated network operations centers) currently requires the reconfiguration of any associated customer virtual private networks. This approach incurs both large systems and operational costs, and results in disruptions to the active customer virtual private networks. Furthermore, this approach is simply not scalable as the size of networks, and the associated number of customer virtual private networks, continues to grow.
While several designs have been proposed in order to address this problem, each of those solutions lacks some functionality or another. For example, one solution utilized a common route-target that was assigned to all network operations centers within a region. While this method did not require extensive reconfiguration of the associated customer virtual private networks when the network operations center footprint changed, it provided no means of distinguishing between network operations center types (e.g., network-facing versus customer-facing). A related issue was the inability to block network-facing network operations center routes from leaking into the customer virtual private networks since there was no easy way of separating them. Furthermore, this design did not allow for the categorization of managed network assets by type, and thus was not scalable from the standpoint of the network management of customer virtual private networks.
As such, a need exists in the art for a method of deriving router configurations of at least one datacenter edge router and at least one provider edge router to support at least one datacenter managing at least one customer virtual private network.